\section{Approach}
\label{section:approach}


Additionally, we would need to identify the different actors (user profiles) and under what circumstances they provided the different types of feedback, not only for the purpose of trust (e.g., avoid fake feedbacks and feedback cheating), but also for identifying whether the feedback provided matches the needs, therefore is more valid and valuable, for the current consumer candidates. (\textit{Kahina maybe you can explain this better :( sorry I tried but this part will certainly need revision})

To express our latter concerns we propose the incorporation of provenance of feedback information for our reputation management design. Provenance of feedback corresponds to both the provenance of objective and subjective feedback and is defined as the information about entities, activities, or people involved in the process that produced the feedback information. This information may well include information about the time, location and service phase when/where the feedback for the evaluation of cloud-based services was provided. \textit{Kahina maybe here we should try to give a short definition for what is provenance of feedbacks- I tried to make up one based on the definition of PROV model}
  

%The main idea in this paper is to consider the provenance of feedback in the evaluation of Services. 

%
%Then the idea would be to get the provenance of feedback information.


%Use of person identification mechanisms?
%The idea behind it would be to avoid fake feedbacks, feedback cheating, etc.


%It may also be interesting to have information about the date when the feedback was provided: was it long after the use of the service or not.



\subsection{Purpose of Feedback provenance}

\textit{1) For Subjective Feedback}

The main use of provenance for Subjective Feedback is related to the clear contextualization or qualification of this feedback. According to the model defined in [?] subjective feedbacks are evaluated by service consumers. Contrary to monitoring information, such feedback cannot be used “as they are”, they need to be considered in the light of the context where they were created. Such contextualization should encompass different elements: who produced the feedback, how the feedback was produced, when it was produced. In this perspective, provenance can be used to define the “who” by providing information about the profile of the person(s) that gave the feedback. Provenance can also be used for the “when” simply by providing timestamps of the feedback creation, identifying if the information was recorded during or after the service consumption. The “how” is a more complex matter, as the production of feedback can take different forms, what should be considered is the underlying model used to collect such information(to be developed and investigated? ).

\textit{2) For Objective Feedback}

Provenance for Objective Feedback has a different role than for Subjective. The use of provenance data for Objective Feedback is not to help the contextualization or the "weighing" of feedback by the identification of profiles (as it is envisaged for Subjective ones), the goal is to ensure that Objective Feedback are collected in an adequate manner (potentially according to the specifications provided in the SLA), are not corrupted, they are also useful to guarantee that the source of the feedback is the entity expected to provide such information and not some third party.
but it should be used as a "partial" basis for further development at least I think still, we need to refine the ideas behind that extract a categorization of potential use and dig deeper to see how, concretely, it could be used.

\subsection{Ontological Design}

The purpose of this section is 1) give a definition of the concepts with which we extend the \textsf{ServiceProv Ontology} in order to represent the provenance of feedbacks and 2) present the whole picture of our ontological design merged with the SLA ontology to support evaluation of services for our reputation management 

\section{Concepts for the Provenance Feedbacks}


\textit{Provenance of Subjective Feedback}

\textit{Kahina - I am not sure yet what we should define there so I leave it blank for the time being. We should discuss on that as long as you define what is subjective feedback for you. Then we can add appropriate concepts or say that we are using existing concepts of PROV-O for the time, location, etc?}


\textit{Provenance of Objective Feedback}

\textit{Kahina - I am adding some concepts here I have defined already but we can of course add some new ones like (e.g., the one about Service Auditing we were talking recently or other you may think? Well I think in both objective and subjective feedback we should discuss what other concepts of other phases of the service lifecycle are interesting to be monitored or reported (you have mentioned this to your email answering my questions alread)?}


\textsf{Monitoring Activity:} is a prov:Activity that monitors different properties of the services during its execution such as the availability of resources (CPU, Memory, Disk, Network) or QoS attributes or non-functional properties (NFPs).  We therefore have two subtypes (Resource Monitoring) and QoSMonitoring.

\textsf{ResourceMonitoring Activity:} is-a Monitoring Activity that monitors the resources for a particular service execution. 

\textsf{NFPMonitoringActivity:} is-a Monitoring Activity that monitors the NFPs for a particular service execution.

\textsf{MonitoringAgent:} is a software agent that is responsible for the  the monitoring activity either for a ResourceMonitoringActivity or a NFPMonitoringActivity.


\textsf{NFPMonitoringRole:} is-a prov:Role that captures the role played by a :MonitoringAgent in a qualified association with a :NFPMonitoringActivity.  


\textsf{PerformanceMonitoringRole:} is-a prov:Role that captures the role played by a :MonitoringAgent in a qualified association with a :NFPMonitoringActivity that monitored the performance of a service execution.

\textsf{SuccessRateMonitoringRole:} is-a prov:Role that captures the role played by a :MonitoringAgent in a qualified association with a :NFPMonitoringActivity that monitored the number of successful invocations of a service.

\textsf{NonAvailabilityMonitoringRole:} is-a prov:Role that captures the role played by a :MonitoringAgent in a qualified association with a :NFPMonitoringActivity that monitored the number of times that a service was not available/ was offline.

\textsf{FailureRateMonitoringRole:} is-a prov:Role that captures the role played by a :MonitoringAgent in a qualified association with a :NFPMonitoringActivity that monitored the number of failures of a service/process to be completed/invoked.

\textsf{ResourceMonitoringRole:} is-a prov:Role that captures the role played by a :MonitoringAgent in a qualified association with a :ResourceMonitoringActivity.

\textsf{wasMonitoredBy} is an object property that has as a domain the :NFP or :Resource class and ranges to the :MonitoringActivity class.

Of course we use concepts of the PROV ontology such as prov: atLocation or prov:atTime to represent the when and where a monitoring agent acted or a monitoring activity took place.

\textit{Kahina-please review those concepts again especially the subtypes of NFPMonitoring Role- then maybe we can use build an example somewhere with some of the concepts if this makes sense- Do you think we can fit such a scenario in the motivating use case or not?}


